Designing the bad day

Open any design file and count the screens. The full inbox, the healthy balance, the completed order. Now count the empty states, the failures, the halfway-through-and-interrupted states. In most files the ratio is embarrassing.

It is not laziness. The good state is the one you can show in a review. Nobody has ever been praised in a design critique for the payment-declined screen.

The states that get remembered

Ask someone about an app they dislike and they will describe a failure. The upload that vanished. The error that said something went wrong and nothing else. The form that cleared itself.

Nobody describes the happy path, because the happy path is invisible when it works. All of the memorable surface area is in the failures, and almost none of the design attention is.

Draw them first

I have started with the error and empty states for a couple of years now. It feels backwards for about a day and then it stops feeling like anything. Two things happen.

First, the good state gets simpler, because you already know what has to be recoverable. Second, you find the missing product decisions early — every honest error message needs someone to have decided what actually happens next, and that decision is usually nobody's.

Say what happened, then what to do

An error has two jobs and they go in one order. What happened, in the reader's words, not the system's. Then the next action, as a thing they can press.

No apologies, no cheerful tone, no red. Someone whose payment just failed is not having a light moment, and a friendly exclamation mark reads as though the product is not taking it seriously either.